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(54) System and method for providing manageability to security information for secured items 



(57) The present invention relates to improved ap- 
proaches for accessing secured digital assets (e.g., se- 
cured items). In general, digital assets that have been 
secured (secured digital assets) can only be accessed 
by authenticated users with appropriate access rights 
or privileges. Each secured digital asset is provided with 
a header portion and a data portion, where the header 
portion includes a pointer to separately stored security 



information. The separately stored security information 
is used to determine whether access to associated data 
portions of secured digital assets is permitted. These im- 
proved approaches can facilitate the sharing of security 
information by various secured digital assets and thus 
reduce the overall storage space for the secured digital 
assets. These improved approaches can also facilitate 
efficient management of security for digital assets. 
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Description 

[0001] The present invention relates to security sys- 
tems for data and, more particularly, to security systems 
that protect data in an enterprise environment. 
[0002] The I ntemet is the fastest growing telecommu- 
nications medium in history. This growth and the easy 
access it affords have significantly enhanced the oppor- 
tunity to use advanced information technology for both 
the public and private sectors. It provides unprecedent- 
ed opportunities for interaction and data sharing among 
businesses and individuals. However, the advantages 
provided by the Internet come with a significantly greater 
element of risk to the confidentiality and integrity of in- 
formation. The Internet is a widely open, public and in- 
ternational network of interconnected computers and 
electronic devices. Without proper security means, an 
unauthorized person or machine may intercept any in- 
formation travelling across the Internet and even get ac- 
cess to proprietary information stored in computers that 
interconnect to the Internet, but are otherwise generally 
inaccessible by the public. 

[0003] There are many efforts in progress aimed at 
protecting proprietary information travelling across the 
Internet and controlling access to computers carrying 
the proprietary information. Cryptography allows people 
to carry over the confidence found in the physical world 
to the electronic world, thus allowing people to do busi- 
ness electronically without worries of deceit and decep- 
tion. Every day hundreds of thousands of people interact 
electronically, whether it is through e-mail, e-commerce 
(business conducted over the Internet), ATM machines, 
or cellular phones. The perpetual increase of informa- 
tion transmitted electronically has lead to an increased 
reliance on cryptography. 

[0004] One oftheongoing efforts in protecting the pro- 
prietary information travelling across the Internet is to 
use one or more cryptographic techniques to secure a 
private communication session between two communi- 
cating computers on the Internet. The cryptographic 
techniques provide a way to transmit information across 
an unsecure communication channel without disclosing 
the contents of the information to anyone eavesdrop- 
ping on the communication channel. Using an encryp- 
tion process in a cryptographic technique, one party can 
protect the contents of the data in transit from access 
by an unauthorized third party, yet the intended party 
can read the data using a corresponding decryption 
process. 

[0005] A firewall is another security measure that pro- 
tects the resources of a private network from users of 
other networks. However, it has been reported that 
many unauthorized accesses to proprietary information 
occur from the inside, as opposed to from the outside. 
An example of someone gaining unauthorized access 
from the inside is when restricted or proprietary informa- 
tion is accessed by someone within an organization who 
is not supposed to do so. Due to the open nature of the 



Internet, contractual information, customer data, exec- 
utive communications, product specifications, and a 
host of other confidential and proprietary intellectual 
property remains available and vulnerable to improper 

5 access and usage by unauthorized users within or out- 
side a supposedly protected perimeter. 
[0006] Many businesses and organizations have 
been looking for effective ways to protect their proprie- 
tary information. Typically, businesses and organiza- 

10 tions have deployed firewalls, Virtual Private Networks 
(VPNs), and Intrusion Detection Systems (IDS) to pro- 
vide protection. Unfortunately, these various security 
means have been proven insufficient to reliably protect 
proprietary information residing on private networks. For 

15 example, depending on passwords to access sensitive 
documents from within often causes security breaches 
when the password of a few characters long is leaked 
or detected. Therefore, there is a need to provide more 
effective ways to secure and protect resources on prr- 

20 vate networks. 

[0007] The invention relates to improved approaches 
for accessing secured digital assets (e.g., secured 
items). In general, digital assets that have been secured 
(secured digital assets) can only be accessed by au- 

25 thenticated users with appropriate access rights or priv- 
ileges. Each secured digital asset is provided with a 
header portion and a data portion, where the header 
portion includes a pointer to separately stored security 
information. The separately stored security information 

30 is used to determine whether access to associated data 
portions of secured digital assets is permitted. These im- 
proved approaches can facilitate the sharing of security 
information by various secured digital assets and thus 
reduce the overall storage space for the secured digital 

35 assets. These improved approaches can also facilitate 
efficient management of security for the secured digital 
assets. 

[0008] The invention can be implemented in numer- 
ous ways, including as a method, system, device, and 

40 computer readable medium. Several embodiments of 
the invention are discussed below. 
[0009] As a method for accessing a secured file, one 
embodiment of the invention includes at least the acts 
of: obtaining the secured file to be accessed, the se- 

45 cured file having a header portion and a data portion; 
retrieving a security information pointer from the header 
portion of the secured file; obtaining security information 
for the secured file using the security information point- 
er; and permitting access to the secured file to the extent 

50 permitted by the security information. 

[0010] As a computer readable medium including at 
least computer program code for accessing a secured 
item, one embodiment of the invention includes at least: 
computer program code for obtaining the secured item 

55 to be accessed, the secured item having a header por- 
tion and a data portion; computer program code for re- 
trieving a security information pointer from the header 
portion of the secured item; computer program code for 
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obtaining security information for the secured item using 
the security information pointer; and computer program 
code for permitting access to the secured item to the 
extent permitted by the security information. 
[0011] As a system for accessing a secured item, 
where the secured item has a header portion and an 
encrypted data portion, and where the header portion 
includes at least a pointer and an encrypted key, one 
embodiment of the invention includes at least: a storage 
device that stores security information for a plurality of 
different secured items, the pointer serving to locate the 
security information associated with secured item; afirst 
decryption module that receives the encrypted key from 
the header portion of the secured item and decrypts the 
encrypted key to obtain a key; an access analyzer that 
determines whether the encrypted data portion is per- 
mitted to be accessed by a requestor based on the se- 
curity information; and a second decryption module that 
decrypts the encrypted data portion using the key to pro- 
duce an unencrypted data portion that the requestor is 
able to access, provided the access analyzer deter- 
mines that the encrypted data portion is permitted to be 
accessed by a requestor. 

[001 2] As a data structure for a secured file, one em- 
bodiment of the invention includes at least a header por- 
tion and a data portion. The header portion contains at 
least a pointer to separately stored security information 
and a key. At least the key portion of the header portion 
is encrypted. The data portion contains at least encrypt- 
ed data of the secured file. 

[001 3] Other objects, features, and advantages of the 
present invention will become apparent upon examining 
the following detailed description of an embodiment 
thereof, taken in conjunction with the attached drawings. 
[001 4] These and otherfeatures, aspects, and advan- 
tages of the present invention will become better under- 
stood with regard to the following description, appended 
claims, and accompanying drawings wherein: 

FIG. 1A shows a basic system configuration in 
which the invention may be practised in accordance 
with an embodiment thereof. 
FIG. 1B shows internal construction blocks of a 
computing device in which the invention may be im- 
plemented and executed. 

FIG. 2A is a block diagram of securing a created 
document. 

FIG. 2B is a block diagram of a secured item access 
system according to one embodiment of the inven- 
tion. 

FIG. 2C is a diagram of a representative data struc- 
ture for a secured file. 

FIG. 3 is a flow diagram of secured document ac- 
cess processing according to one embodiment of 
the invention. 

FIG. 4A illustrates a data organization item accord- 
ing to one embodiment of the invention. 
FIG. 4B illustrates exemplary tables for use with the 



data organization illustrated in FIG. 4A. 
FIG. 5 is a block diagram of a file security manage- 
ment system according to one embodiment of the 
invention. 

5 FIGs. 6A and 6B are flow diagrams of secured file 
portability processing according to one embodi- 
ment of the invention. 

[0015] The present invention relates to improved ap- 
proaches for accessing secured digital assets (e.g., se- 
cured items). In general, digital assets that have been 
secured (secured digital assets) can only be accessed 
by authenticated users with appropriate access rights 
or privileges. Each secured digital asset is provided with 
a header portion and a data portion, where the header 
portion includes a pointer to separately stored security 
information. The separately stored security information 
is used to determine whether access to associated data 
portions of secured digital assets is permitted. These im- 
proved approaches can facilitate the sharing of security 
information by various secured digital assets and thus 
reduce the overall storage space for the secured digital 
assets. These improved approaches can also facilitate 
efficient management of security for the secured digital 
assets. 

[0016] Digital assets may include, but not be limited 
to, various types of documents, multimedia files, data, 
executable code, images and text. In the context of the 
present invention, digital assets may also include direc- 
tories/folders as well as any OS-addressable resources 
(e.g. a thread to a port, or a device). The present inven- 
tion is particularly suitable in an inter/intra enterprise en- 
vironment. 

[0017] In the following description, numerous specific 
details are set forth in order to provide a thorough un- 
derstanding of the present invention. However, it will be- 
come obvious to those skilled in the art that the present 
invention may be practised without these specific de- 
tails. The description and representation herein are the 
common means used by those experienced or skilled in 
the art to most effectively convey the substance of their 
work to others skilled in the art. In other instances, well- 
known methods, procedures, components, and circuitry 
have not been described in detail to avoid unnecessarily 
obscuring aspects of the present invention. 
[001 8] Reference herein to "one embodiment" or "an 
embodiment" means that a particular feature, structure, 
or characteristic described in connection with the em- 
bodiment can be included in at least one embodiment 
of the invention. The appearances of the phrase "in one 
embodiment' in various places in the specification are 
not necessarily all referring to the same embodiment, 
nor are separate or alternative embodiments mutually 
exclusive of other embodiments. Further, the order of 
blocks in process flowcharts or diagrams representing 
one or more embodiments of the invention do not inher- 
ently indicate any particular order nor imply any limita- 
tions in the invention. 
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[001 9] Embodiments of the present invention are dis- 
cussed herein with reference to FIGs. 1 A - 6B. However, 
those skilled in the art will readily appreciate that the 
detailed description given herein with respect to these 
figures is for explanatory purposes as the invention ex- 
tends beyond these limited embodiments. 
[0020] FIG. 1 A shows a basic system configuration in 
which the present invention may be practised in accord- 
ance with one embodiment thereof. Documents or files 
may be created using an authoring tool executed on a 
client computer 1 00, which may be a desktop computing 
device, a laptop computer, or a mobile computing de- 
vice. Exemplary authoring tools may include application 
programs such as Microsoft Office (e.g., Microsoft 
Word, Microsoft PowerPoint, and Microsoft Excel), Ado- 
be FrameMakerand Adobe Photoshop. 
[0021] According to one embodiment, the client com- 
puter 100 is loaded with a client module that is a linked 
and compiled, or interpreted, version of one embodi- 
ment of the present invention and is capable of commu- 
nicating with a server 104 or 106 over a data network 
(e.g., the Internet or a local area network). According to 
another embodiment, the client computer 1 00 is coupled 
to the server 1 04 through a private link. As will be further 
explained below, a document or file created by an au- 
thoring tool can be secured by the client module. The 
client module, when executed, is configured to ensure 
% that a secured document is secured at all times in a store 
(e.g., a hard disk or other data repository). The secured 
documents can only be accessed by users with proper 
access privileges. In general, an access privilege or ac- 
cess privileges for a user may include, but not be limited 
to, a viewing permit, a copying permit, a printing permit, 
an editing permit, a transferring permit, an uploading/ 
downloading permit, and a location permit. 
[0022] According to one embodiment, a created doc- 
ument is caused to go through an encryption process 
that is preferably transparent to a user. In other words, 
the created document is encrypted or decrypted under 
the authoring application so that the user is not aware 
of the process. A key (referred to herein as a user key) 
can be used to retrieve a file key to decrypt an encrypted 
document. Typically, the user key is associated with an 
access privilege for the user or a group of users. For a 
given secured document, only a user with a proper ac- 
cess privilege can access the secured document. 
[0023] In one setting, a secured document may be up- 
loaded via the network 1 1 0 from the computer 1 00 to a 
computing or storage device 1 02 that may serve as a 
central repository. Although not necessary, the network 
110 can provide a private link between the computer 1 00 
and the computing or storage device 102. Such link may 
be provided by an internal network in an enterprise or a 
secured communication protocol (e.g., VPN and HT- 
TPS) over a public network (e.g., the Internet). Alterna- 
tively, such link may be simply provided by a TCP/IP link. 
As such, secured documents on the computer 1 00 may 
be remotely accessed. 



[0024] In another setting, the computer 100 and the 
computing or storage device 102 are inseparable, in 
which case the computing or storage device 102 may 
be a local store to retain secured documents or receive 
5 secured network resources (e.g., dynamic Web con- 
tents, results of a database query, or a live multimedia 
feed). Regardless of where the secured documents or 
secured sources are actually located, a user, with proper 
access privilege, can access the secured documents or 

io sources from the computer 1 00 orthe computing or stor- 
age device 102 using an application (e.g., Internet Ex- 
plorer, Microsoft Word or Acrobat Reader). 
[0025] The server 1 04, also referred to as a local serv- 
er, is a computing device coupled between a network 

15 108 and the network 110. According to one embodi- 
ment, the server 1 04 executes a local version of a server 
module. The local version is a localized server module 
configured to service a group of designated users or cli- 
ent computers, or a location. Another server 106, also 

20 referred to as a central server, is a computing device 
coupled to the network 108. The server 106 executes 
the server module and provides centralized access con- 
trol (AC) managementfor an entire organization or busi- 
ness. Accordingly, respective local modules in local 

25 servers, in coordination with the central server, form a 
distributed mechanism to provide distributed AC man- 
agement. Such distributed access control management 
ensures the dependability, reliability and scalability of 
centralized AC management undertaken by the central 

30 server for an entire enterprise or a business location. 
[0026] FIG. 1B shows internal construction blocks of 
a computing device 1 1 8 in which one embodiment of the 
present invention may be implemented and executed. 
The computing device 118 may correspond to a client 

35 device (e.g., computer 100, computing or storage de- 
vice 1 02 in FIG. 1 A) or a server device (e.g., server 1 04, 
106 in FIG. 1A). As shown in FIG. 1B, the computing 
device 118 includes a central processing unit (CPU) 1 22 
interfaced to a data bus 1 20 and a device interface 1 24. 

40 CPU 1 22 executes instructions to process data and per- 
haps manage all devices and interfaces coupled to data 
bus 120 for synchronized operations. The instructions 
being executed can, for example, pertain to drivers, op- 
erating system, utilities or applications. A device inter- 

45 face 1 24 may be coupled to an external device, such as 
the computing device 102 of FIG. 1A; hence, the se- 
cured documents therefrom can be received into mem- 
ory 132 or storage 136 through data bus 120. Also in- 
terfaced to data bus 120 is a display interface 126, a 

so network interface 128, a printer interface 130 and a flop- 
py disk drive interface 138. Generally, a client module, 
a local module or a server module of an executable ver- 
sion of one embodiment of the present invention can be 
stored to storage 136 through floppy disk drive interface 

55 138, network interface 1 28, device interface 1 24 or other 
interfaces coupled to data bus 120. Execution of such 
module by CPU 122 can cause the computing device 
118 to perform as desired in the present invention. In 
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one embodiment, the device interface 124 provides an 
interface for communicating with a capturing device 125 
(e.g., a fingerprint sensor, a smart card reader or a voice 
recorder) to facilitate the authentication of a user of the 
computing device 118. 

[0027] Main memory 132, such as random access 
memory (RAM), is also interfaced to data bus 1 20 to pro- 
vide CPU 122 with instructions and access to memory 
storage 1 36 for data and other instructions. In particular, 
when executing stored application program instructions, 
such as for document securing or document accessing, 
CPU 122 is caused to manipulate the data to achieve 
results contemplated by the program instructions. 
Read-Oniy Memory (ROM) 134 is provided for storing 
executable instructions, such as a basic input/output op- 
eration system (BIOS) for operation of keyboard 140, 
display 126 and pointing device 142 that may be 
present. 

[0028] In one embodiment, the computing or storage 
device 102 is capable of storing secured items (e.g., se- 
cured files) in the main memory 132 or the storage 136. 
The main memory 132 provides non-persistent (i.e., vol- 
atile) storage for the secured items and the storage 1 36 
provides persistent (i.e., nonvolatile) storage forthe se- 
cured items. Hence, the computing or storage device 
102, or more particularly, the main memory 132 and/or 
the storage 136, can act as a storage device for the se- 
cured items. 

[0029] Referring now to FIG. 2A, a block diagram of 
securing a created document 200 is shown according 
to one embodiment of the invention. After the document 
200 is created with an application or authoring tool and 
upon an activation of a "Save," "Save As" or "Close" 
command or automatic saving invoked by an operating 
system, the application itself or another application, the 
created document 200 is caused to undergo a securing 
process 201. The securing process 201 starts with an 
encryption process 202, namely, the document 200 that 
has been created or is being written into a store is en- 
crypted by a cipher with a file key. In other words, the 
encrypted document could not be opened without the 
file key (i.e., a cipher key). 

[0030] A set of access rules 204 for the document 200 
is received and associated with a header 206. In gener- 
al, the access rules 204 determine or regulate who and/ 
or how the document 200, once secured, can be ac- 
cessed. In some cases, the access rules 204 also de- 
termine or regulate when or where the document 200 
can be accessed. Typically, a header is a file structure, 
small in size and includes, or perhaps links to, security 
information about a resultant secured document. De- 
pending on an exact implementation, the security infor- 
mation can be entirely included in a header or pointed 
to by a pointer that is included in the header. According 
to one embodiment, the access rules 204, as part of the 
security information, are included in the header 206. Ac- 
cording to another embodiment, the access rules 204, 
as part of the security information, are separately stored 



from the document 200 but referenced by one or more 
pointers or links therein. According to still another em- 
bodiment, the pointers in the header 206 can point to 
different versions of security information providing dif- 

5 ferent access control depending on user's access priv- 
ilege. The security information or the header 206 further 
includes a file key. Some or all of the header 206 can 
then be encrypted by a cipher with a user key associated 
with an authorized user to an encrypted header21 0. The 

10 encrypted header 21 0 is attached to the encrypted doc- 
ument 212 to generate a secured document 208. 
[0031] It is understood that a cipher may be imple- 
mented based on one of many encryption/decryption 
schemes. Examples of such schemes may include, but 

15 not be limited to, Data Encryption Standard algorithm 
(DES), Blowfish block cipher and Twofish cipher. There- 
fore, the operations of the present invention are not lim- 
ited to a choice of those commonly-used encryption/de- 
cryption schemes. Any encryption/decryption scheme 

20 that is effective and reliable may be used. Hence, the 
details of encryption/decryption schemes are not further 
discussed herein so as to avoid obscuring aspects of 
the present invention. 

[0032] To access the secured document 208, one 
25 needs to obtain the file key that is used to encrypt the 
document. To obtain the file key, one needs to be au- 
thenticated to get a user or group key and pass an ac- 
cess test in which the access rules in the security infor- 
mation are measured against the user's access privi- 
30 lege. 

[0033] It should be noted that the header in a secured 
document may be configured differently than noted 
above without departing from the principles of the 
present invention. For example, a secured document 

35 may include a header with a plurality of encrypted head- 
ers, each can be accessible only by one designated user 
or a group users. Alternatively, a header in a secured 
document may include more than one set of security in- 
formation or pointers thereto, each set being for one 

^0 designated user or a group of users while a single file 
key can be used by all. Some or all of the access rules 
may be viewed or updated by users who can access the 
secured document. 

[0034] In general, the encryption process and its 
45 counter process, decryption, are implemented in a filter 
or a software module that is activated when a secured 
document or item is involved. According to one embod- 
iment in an operating system, the software module can 
be configured to control access to some digital assets 
50 (e.g. , a port or a device) that may not be encrypted. How- 
ever, an access to a secured port or device can trigger 
the software module to operate to control access there- 
to. 

[0035] As will be further described below, to access a 
55 secured document, a user needs a user key or keys to 
decrypt the encrypted security information or at least a 
portion of the header first. In one embodiment, the key 
or keys are associated with a user's login to a local serv- 
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er or a central server. Appropriate access privileges as- 
sociated with the user are validated if the user has been 
authenticated or previously registered with the server 
and properly logged in. Depending on the permission or 
the access privileges, the access rules for the secured 5 
document determine whether the contents of the docu- 
ment shall be revealed to the user 
[0036] According to one embodiment, the access 
rules are present in a markup language, such as HTML, 
SGML and XML. I n a preferred embodiment, the markup 
language is Extensible Access Control Markup Lan- 
guage (XACML) that is essentially an XML specification 
for expressing policies for information access. In gener- 
al, XACML can address fine-grained control of author- 
ized activities, the effect of characteristics of the access 
requestor, the protocol over which the request is made, 
authorization based on classes of activities, and content 
introspection (i.e., authorization based on both the re- 
questor and attribute values within the target where the 
values of the attributes may not be known to the policy 
writer). In addition, XACML can suggest a policy author- 
ization model to guide implementers of the authorization 
mechanism. 

[0037] In general, a document is encrypted with a ci- 
pher (e.g., a symmetric or asymmetric encryption 
scheme). Encryption is the transformation of data into a 
form that is impossible to read without appropriate 
knowledge (e.g., a key). Its purpose is to ensure privacy 
by keeping information hidden from anyone to whom it 
is not intended, even those who have access to other 
encrypted data. Decryption is the reverse of encryption. 
Encryption and decryption generally require the use of 
some secret information, referred to as a key. For some 
encryption mechanisms, the same key is used for both 
encryption and decryption; for other mechanisms, the 
keys used for encryption and decryption are different. 
[0038] For the purpose of controlling the access to the 
document, the key or keys, referred collectively to as a 
file key, may be the same or different keys for encryption 
and decryption and are preferably included in the secu- 
rity information contained in or pointed to by the header 
and, once obtained, can be used to decrypt the encrypt- 
ed document. To ensure that the key is not to be re- 
trieved or accessible by anyone, the key itself is guarded 
by the access rules. If a user requesting the document 
has the proper access privileges that can be granted by 
the access rules, the key will be retrieved to proceed 
with the decryption of the encrypted document. 
[0039] To ensure that the security information or the 
header is not readily revealed, at least a portion of the 
header itself can be encrypted with a cipher. Depending 
on an exact implementation, the cipher for the header 
may or may not be identical to the one used for the doc- 
ument. The key (referred to as a user key) to decrypt 
the encrypted header can, for example, be stored in a 
local store of a terminal device and activated only when 
the user associated with it is authenticated. As a result, 
only an authorized user can access the secured docu- 



ment. 

[0040] Optionally, the two portions (i.e., the header 
(possibly encrypted) and the encrypted document) can 
be encrypted again and only decrypted by a user key. 
In another option, the encrypted portions (either one or 
all) can be error-checked by an error-checking portion, 
such as using a cyclical redundancy check to ensure 
that no errors have been incurred to the encrypted por- 
tion^) or the secured document. 
[0041] FIG. 2B is a block diagram of a secured item 
access system 240 according to one embodiment of the 
invention. The secured item access system 240 oper- 
ates to process a secured item 242 on behalf of a re- 
questor to either permit or deny access to its contents. 
The secured item 242 is, for example, a secured file, 
such as a secured document. 

[0042] The secured item 242 includes a header por- 
tion 244 and an encrypted data portion 246. The header 
portion 244 includes at least a pointer 248. When a re- 
questor requests access to the secured item 242, the 
pointer 248 from the header portion 244 is supplied to 
a storage device 250. The pointer 248 is used to locate 
security information 252 stored in the storage device 
250. In this embodiment, the security information 252 is 
not encrypted; however, in another embodiment, the se- 
curity information 252 could be further secured by en- 
cryption. Hence, the pointer 248 is used to retrieve the 
security information 252 from the storage device 250. 
[0043] The header portion 244 also includes at least 
an encrypted file key 254. The encrypted file key 254 is 
encrypted in this embodiment to secure the file key. 
Hence, the encrypted file key 254 is supplied to a first 
decryption module 256. The first decryption module 256 
also receives a user key. In one embodiment, the user 
key is a private key, and in another embodiment, the us- 
er key is a public key. In any case, the first decryption 
module 256 operates to decrypt the encrypted file key 
254 using the user key and thus produces an unencrypt- 
ed file key 258. 

[0044] The security information 252 typically includes 
at least access rules for access to the encrypted data 
portion 246 of the secured item 242. The security infor- 
mation 252 is supplied to an access rules analyzer 260. 
The access rules analyzer 260 also receives user priv- 
ileges associated with the requestor. The access rules 
analyzer 260 examines the user privileges and the se- 
curity information 252, namely, the access rules con- 
tained therein, to determine whether the requestor has 
sufficient privileges to gain access to the encrypted data 
portion 246 of the secured item 242. The access rules 
analyzer 260 outputs an access decision to an access 
controller 262. The access controller 262 receives the 
access decision and the file key 258. When the access 
controller 262 determines that the access decision does 
not permit the requestor to gain access to the encrypted 
data portion 246 of the secured item 242, then access 
to the encrypted data portion 246 for the secured item 
242 is denied. Alternatively, when the access controller 
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262 determines that the access decision does permit the 
requestor to gain access to the encrypted data portion 
246 of the secured item 242, then the file key 258 is 
supplied to a second decryption module 262. In addition, 
the encrypted data portion 246 of the secured item 242 
(i.e., the data of the secured item 242) is supplied to the 
second decryption module 264. The second decryption 
module 264 then operates to decrypt the encrypted data 
portion 246 using the file key 258 to produce an unen- 
crypted data portion 266. The unencrypted data portion 
266 is then made available to the requestor, thereby per- 
mitting the requestor to gain access to the data associ- 
ated with the secured item 242. 

[0045] According to the invention, the header portion 
of a secured item is able to be reduced in size due to 
the use of a pointer. More particularly, the pointer in the 
header portion points to separately stored security in- 
formation. Since the size of the pointer is substantially 
smaller than the size of the security information pointed 
to, the overall size of the secured item is reduced. In one 
embodiment, the pointer is structured in a fixed number 
of bits so that the size of the pointer is constant. 
[0046] Additionally, with security information being 
separately stored, the security information is able to be 
shared across different documents, thus reducing the 
storage burdens for storage of secured items. Changes 
or modifications to security rules or other security infor- 
mation can be more easily made because changes to 
the secured items themselves are not necessary. That 
is, changes to security information stored to a storage 
device are performed without alterations to the corre- 
sponding secured items. 

[0047] With respect to manageability of secured 
items, one feature of the invention is that through use of 
pointers to security information (stored at a storage de- 
vice separately from the secured files) different secured 
files are able to share the same stored security informa- 
tion or parts thereof. For example, multiple secured files 
can utilize identical pointers such that they all share the 
same security information stored on a local storage de- 
vice. Consequently, managing the security provided to 
the secured files is at least in part dependent upon the 
security information. Hence, by being able to share com- 
mon security information, not only can the amount of se- 
curity information storage space being utilized be sub- 
stantially reduced, but also access to the associated se- 
cured files can be managed more efficiently. 
[0048] FIG. 2C is a diagram of a representative data 
structure 280 for a secured file. For example, the se- 
cured file can be the secured item 242 illustrated in FIG. 
2B.The data structure 280 includes a header (or header 
portion) 282 and an encrypted data portion 284. The 
header 282 includes a flag bit 286, at least one pointer 
288, and an encrypted file key 290. The flag bit 286 in- 
dicates whether or not the data structure pertains to a 
file that is secured. The at least one pointer 288 points 
to a remote data structure 292 stored in a storage de- 
vice. The storage device is typically a local storage de- 



vice. In other words, the data structure 280 and the re- 
mote data structure 292 are typically stored on a com- 
mon machine (e.g., desktop or portable computer). The 
data structure 292 stores security information 294. The 
5 data structure 292 storing the security information 294 
can vary depending upon implementation. However, as 
shown in FIG. 2C, the data structure 292 for the security 
information 294 includes a user identifier (ID) 296-1 , 
rules (access rules) 296-2 and other 296-3. The other 

10 296-3 is additional space for other information to be 
stored within the security information 294. For example, 
the other information 296-3 may be used to include other 
information facilitating secure access to the secured file, 
such as version number or author identifier. The en- 

15 crypted file key 290 is normally itself decrypted and then 
used to decrypt the encrypted data portion 214 so as to 
access the content or data of the secured file. 
[0049] FIG. 3 is a flow diagram of secured document 
access processing 300 according to one embodiment 

20 of the invention. The secured document access 
processing 300 is typically performed by a computer. 
The computer can be a local computer or a remote com- 
puter. Further, the computer can also be considered 
both a local and a remote computer that operate in a 

25 client-server fashion. 

[0050] The secured document access processing 300 
can be invoked when a requestor selects a document 
to be accessed. The document is a particular type of file 
(for example, design.doc). Therefore, more generally, 

30 the requestor selects a file in a folder or among other 
files to be accessed. Once the document has been se- 
lected, the secured document access processing 300 is 
invoked. Initially, the selected documentto be accessed 
is obtained 302. Typically, the selected document will 

35 have a header portion and a data portion. Next, a secu- 
rity information pointer is retrieved 304 from the header 
portion of the selected document. Here, the header por- 
tion of the selected document includes at least the se- 
curity information pointer that points to an address loca- 

40 tion where the corresponding security information is lo- 
cated. Next, the security information for the selected 
document is obtained 306 using the security information 
pointer. 

[0051] A decision 308 then determines whether the 
45 security information permits the requested access. In 
this regard, the security information may or may not be 
encrypted so that it remains secure while stored on the 
local storage. If the security information is encrypted, 
the security information would be decrypted (e.g., 
so through use of a user key) to gain access to the security 
information. The security information contains, among 
other things, access rules. These access rules are used 
by the decision 308 in determining whetherthe request- 
ed access is permitted. Namely, the access rules are 
55 compared to privileges associated with the requestor for 
the selected document. When the decision 308 deter- 
mines that the security information (namely the access 
rules) does not permit the requested access, then an 
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access denied message Is provided 310 to the reques- 
tor. On the other hand, when the decision 308 deter- 
mines that the security information does permit the re- 
quested access, then the data portion of the selected 
document is decrypted 312. Typically, the header por- 
tion also includes a file key. The file key is itself normally 
encrypted and can be decrypted with a user key. The 
file key can be used to decrypt the encrypted data por- 
tion of the selected document. Once the data portion has 
been decrypted, the data portion is provided 314 to the 
requestor. Here, the requestor has gained access to the 
selected document. Following the operation 314, as well 
as following the operation 31 0, the secured access doc- 
ument processing 300 is complete and ends. 
[0052] The security information is stored to a storage 
device and located through use of a pointer that is pro- 
vided with a header portion of a secured file (document). 
The manner in which the security information is stored 
within the storage device can vary depending upon im- 
plementation. In one embodiment, the pointer directly 
points to a storage location (i.e., memory location) within 
the storage device. Stored at the storage location des- 
ignated by the pointer is the security information. As an 
example, the security information 294 pointed to by the 
pointer 288 shown in FIG.2C can be located in this man- 
ner. 

[0053] In another embodiment, the security informa- 
tion can be stored in a database-type organization. FIG. 
4A illustrates a data organization 400 according to one 
embodiment of the invention. According to the data or- 
ganization 400, the association between a secured file 
402 and its associated security information as separate- 
ly stored in a storage device is illustrated. The secured 
file 402 includes a header portion 404 and a data portion 
406. The header portion 404 includes at least a pointer 
408 that points to a security information table 41 0. The 
security information table 410 can then, in turn, include 
a pointer to a rules table 41 2 that can store access rules. 
In general, the security information table 41 0 is encrypt- 
ed by one or more keys in a key table 414. The tables 
410, 412 and 414 of the data organization 400 can be 
provided within a database. 

[0054] FIG. 4B illustrates exemplary tables for the se- 
curity information table 41 0, the rules table 41 2 : and the 
key table 414 illustrated in FIG. 4A. The security infor- 
mation table 410 is a main table that is addressed 
through use of a memory address maintained by an op- 
erating system. The pointer 408 points to one of the 
rows, namely, memory addresses (e.g., operating sys- 
tem addresses), of the security information table 410. 
The rows of the security information table 410 in turn 
can point to other tables or include data therein. As 
shown in FIG. 4B, the columns of the security informa- 
tion table 410 include an operating system address, a 
policy identifier column and an owning group identifier 
column. The operating system address column can 
serve as an index to the security information table 410. 
The policy identifier column of the security information 



table 410 includes pointers to particular rows in the rule 
table 412. The rules within the rules table 412 can be 
provided within a variety of different formats. The rules 
table 41 2 shown in FIG. 4B provides the rules expressed 
5 in a markup language format (such as extensible 
Markup Language (XML)). The owning group identifier 
column of the security information table 410 includes 
pointers pertaining to group identifiers. These pointers 
pertaining to the group identifiers point to rows within 

10 the key table 414. As shown in FIG. 4B, each row within 
the key table 414 can store a public key and a private 
key. In other words, each of the group identifiers is as- 
sociated with a pair of public and private keys. Depend- 
ing on implementation and a specific stage of a secured 

15 file being accessed, one or both of the public and private 
keys may be encrypted or readily used to encrypt or de- 
crypt the security information table 41 0. In any case, on- 
ly an authenticated user (in a user group identified by 
one of the group identifiers) can retrieve one of the keys 

20 to access the secured file 402. 

[0055] FIG. 5 is a block diagram of a file security man- 
agement system 500 according to one embodiment of 
the invention. The file security management system 500 
includes a security information manager 502 and a da- 

25 tabase 504. An administrator 506 interacts with the se- 
curity information manager 502 typically through a 
graphical user interface (GUI). In this manner, the ad- 
ministrator 506 is able to store, modify or delete infor- 
mation in the database 504. By altering the security in- 

30 formation stored in the database 504, the administrator 
is able to manage the nature of the security provided to 
associated files or documents. The database 504 in- 
cludes the security information arranged in a plurality of 
tables. The tables include a security information table 

35 508, a rules table 51 0 and a key table 512. For example, 
using the security information manager 502, the admin- 
istrator 506 can provide new keys for the key table 512, 
such as to rotate keys for security reasons. As another 
example, the administrator 506 might interact with the 

40 security information manager to store new access rules 
(or policies) to the rules table 51 0. Hence, the separate 
and distributed storage of the security information and 
the user of pointers provides an efficient data arrange- 
ment that allows security information to be efficiently 

45 stored, modified and shared. 

[0056] In general, a secured item (e.g., secured file) 
with its pointer to separately stored security information 
are stored relative to one another. Hence, moving the 
location of the secured item requires adjustment to the 

50 pointers, particularly when the movement is to another 
storage device. In other words, although stored in an 
efficient and manageable format, the secured item and 
its security information are not readily portable relative 
to one another as an association to the security infor- 
ms mation must be maintained. Processing discussed be- 
low is able to provide temporary portability for the move- 
ment of the secured item. 

[0057] FIGs. 6A and 6B are flow diagrams of secured 
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file portability processing 600 according to one embod- 
iment of the invention. The secured file portability 
processing 600 pertains to processing carried out on a 
secured file when such file is being moved from its 
present storage device to a different storage device, s 
Typically, these different storage devices are associated 
with different computers. The processing shown in FIG. 
6A is typically performed by the computer initially storing 
the secured file, and the processing shown in FIG. 6B 
is typically performed by a different computer. 10 
[0058] The secured file portability processing 600 be- 
gins with a decision 602 that determines whether a re- 
quest to move a secured file to a different storage device 
has been received. When the decision 602 determines 
that such a request has not yet been received, the se- 15 
cured file portability processing 600 awaits such a re- 
quest. Once the decision 602 determines that a request 
to move a secured file to a different storage device has 
been received, the secured file portability processing 
600 begins its processing. Initially, a security information 20 
pointer is retrieved 604 from a header portion of the se- 
cured file. Security information for the secured file is 
then obtained 606 using the security information pointer 
Typically, the security information is not encrypted at this 
point. Hence, the security information is encrypted. The 25 
security information can be encrypted using a key (e.g., 
public key). Next, the security information pointer in the 
header is replaced 608 with the encrypted security in- 
formation. 

[0059] After the security information pointer has been 30 
replaced with the encrypted security information, the se- 
cured file is portable and can thus be moved 61 0 to the 
different storage device. Once moved, the secured file 
can be stored to the different storage device in its port- 
able format or additional processing as provided in FIG. 35 
6B can be performed to store the secured file in a more 
efficient and manageable format. 
[0060] When such additional processing is per- 
formed, the encrypted security information is initially re- 
trieved 612 from the header of the secured file. The en- 40 
crypted security information is then decrypted 613. 
Once decrypted 613, the security information is stored 
614 to the different storage device. The different ma- 
chine that is performing the processing shown in FIG. 
6B has the security information stored therein. Next, a 45 
pointer to the stored location of the security information 
is generated 61 6. Thereafter, the encrypted security in- 
formation in the header is replaced 61 8 with the pointer. 
At this point, the secured file has been altered such that 
it includes the pointer and not the encrypted security in- so 
formation. Consequently, the secured file is now more 
efficiently stored and more manageable. Following the 
operation 618, the secured file portability processing 
600 is complete and ends. 

[0061] The invention is preferably implemented by 55 
software, but can also be implemented in hardware or 
a combination of hardware and software. The invention 
can also be embodied as computer readable code on a 



computer readable medium. The computer readable 
medium is any data storage device that can store data 
which can thereafter be read by a computer system. Ex- 
amples of the computer readable medium include read- 
only memory, random-access memory, CD-ROMs, 
DVDs, magnetic tape, optical datastorage devices, and 
carrier waves. The computer readable medium can also 
be distributed over network-coupled computer systems 
so that the computer readable code is stored and exe- 
cuted in a distributed fashion. 

[0062] The various embodiments, implementations 
and features of the invention noted above can be com- 
bined in various ways or used separately. Those skilled 
in the art will understand from the description that the 
invention can be equally applied to or used in other var- 
ious different settings with respect to various combina- 
tions, embodiments, implementations or features pro- 
vided in the description herein. 

[0063] The advantages of the invention are numer- 
ous. Different embodiments or implementations may 
yield one or more of the following advantages. One ad- 
vantage of the invention is that access rules or criteria 
are able to be stored separate from the corresponding 
secured items. Another advantage of the invention is 
that security information to be used with secured items 
is able to be readily altered by a security administrator. 
Still another advantage of the invention is that central- 
ized, dynamic security management is facilitated. Yet 
another advantage of the invention is that the security 
approaches of the invention are useful for not only files 
but also non-file resources, even non-encryptable re- 
sources such as pipes/streams, ports and devices. 
[0064] The foregoing description of embodiments is 
illustrative of various aspects/embodiments of the 
present invention. Various modifications to the present 
invention can be made to the preferred embodiments by 
those skilled in the art without departing from the true 
spirit and scope of the invention as defined by the ap- 
pended claims. Accordingly, the scope of the present 
invention is defined by the appended claims rather than 
the foregoing description of embodiments. 



Claims 

1 . A method for accessing a secured file, said method 
comprising:- 

(a) obtaining the secured file to be accessed, 
the secured file having a header portion and a 
data portion; 

(b) retrieving a security information pointer from 
the header portion of the secured file; 

(c) obtaining for the secured file security infor- 
mation pointed to by the security information 
pointer; and 

(d) permitting access to the secured file to an 
extent permitted by the security information. 
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2. A method as recited in claim 1 , wherein said per- 
mitting step (d) comprises:- 

(d1) retrieving a file key from the header por- 
tion; and 5 
(d2) decrypting the data portion of the secured 
file using the file key. 

3. A method as recited in claim 1 or 2, wherein a re- 
questor desires to access the secured file, the re- 10 
questor having requestor characteristics; 

wherein said permitting step (d) comprises:- 

retrieving at least one access rule from the se- 
curity information; and 15 
determining whether the requestor is permitted 
to access the secured file based on the at least 
one access rule and the requestor characteris- 
tics. 

20 

4. A method as recited in any preceding claim, where- 
in a requestor desires to access the secured file, 
and wherein said method further comprises:- 

(e) decrypting, following said obtaining step (c) 25 
and before said permitting step (d), the security 
information. 

5. A method as recited in claim 4, wherein said de- 
crypting step (e) of the security information is per- 30 
formed using a key associated with the requestor 
and the key is a user key. 

6. A method as recited in claim 4 or 5, wherein the se- 
curity information is located locally in a client ma- 35 
chine from which the secured file is being accessed 

or remotely in a computing machine coupled to the 
client machine over a network. 

7. A computer readable medium including at least *o 
computer program code for accessing a secured 
item, said computer readable medium comprises:- 

computer program code for obtaining the se- 
cured item to be accessed, the secured item *5 
having a header portion and a data portion; 
computer program code for retrieving a security 
information pointer from the header portion of 
the secured item; 

computer program code for obtaining for these- so 
cured item security information pointed to by 
the security information pointer; and 
computer program code for permitting access 
to the secured item to an extent permitted by 
the security information. 55 

8. A computer readable medium as recited in claim 7, 
wherein said computer program code operates the 



method of any one of claims 2 to 6. 

9. A system for accessing a secured item, the secured 
item having a header portion and an encrypted data 
portion, the header portion including a pointer and 
an encrypted key, said system comprising:- 

a storage device, said storage device storing 
security information for a plurality of different 
secured items, the pointer serving to locate the 
security information associated with secured 
item; 

a first decryption module, said first decryption 
module receiving the encrypted key from the 
header portion of the secured item and decrypt- 
ing the encrypted key to obtain a key; 
an access analyzer operatively connected to 
said storage device, said access rules analyzer 
determines whether the encrypted data portion 
is permitted to be accessed by a requestor 
based on the security information; and 
a second decryption module operatively con- 
nected to said access analyzer, said second 
decryption module decrypting the encrypted 
data portion using the key to produce an unen- 
crypted data portion that the requestor is able 
to access, provided said access analyzer de- 
termines that the encrypted data portion is per- 
mitted to be accessed by the requestor. 

10. A system as recited in claim 9, wherein the security 
information includes at least an access rule; where- 
in the requestor has user privileges associated 
therewith; and wherein said access analyzer deter- 
mines whether the encrypted data portion is permit- 
ted to be accessed by the requestor based on the 
access rule and the user privileges. 

11. A data structure for a secured file, said data struc- 
ture comprising:- 

a header portion containing at least a pointer to 
separately stored security information and a 
key, at least the key portion of said header por- 
tion is encrypted; and 

a data portion containing at least encrypted da- 
ta of the secured file. 

12. A data structure as recited in claim 11 , wherein the 
pointer is used to access the separately stored se- 
curity information which is in turn used to determine 
whether a particular requestor for access to the se- 
cured file is permitted, and then when access is per- 
mitted, providing the key to the requestor so that the 
encrypted data in said data portion can thereafter 
be decrypted and thus accessed. 

1 3. A data structure as recited in claim 1 1 or 1 2, wherein 
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the pointer points to a database that stores the sep- 
arately stored security information for a plurality of 
secured files. 

14. A data structure as recited in claim 1 2 or 1 3, wherein 
like separately stored secured information can be 
shared by a plurality of secured files. 
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